Skip to content

Add tiger mcp get command #136

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
nathanjcochran merged 15 commits into from
Jan 21, 2026
Merged

Add tiger mcp get command #136

nathanjcochran merged 15 commits into from
Jan 21, 2026

Conversation

@nathanjcochran
Copy link
Member

@nathanjcochran nathanjcochran commented Jan 13, 2026 •
edited
Loading

This PR adds a new tiger mcp get <type> <name> command that allows users to inspect detailed information about specific MCP capabilities (tools, prompts, resources, and resource templates).

New Command

The tiger mcp get command provides detailed, human-readable information about MCP capabilities:

# Get details about a tool
tiger mcp get tool service_create

# Get details about a prompt
tiger mcp get prompt setup-timescaledb-hypertables

# Output as JSON or YAML
tiger mcp get tool service_create -o json
tiger mcp get tool service_create -o yaml

It is also aliased as tiger mcp show and tiger mcp describe (to match the tiger service get aliases).

Note that I first tried outputting the information in a table (when not requesting JSON/YAML formatted output), but I found it too difficult to read due to the amount of text in the tool descriptions and input/output schemas. I therefore decided use a raw text format roughly similar to how Claude Code displays tools when you inspect one via /mcp (though there are some differences, such as the fact that I show the output schema as well as the input schema). I'm open to other thoughts and feedback on this though.

Additional Changes

  • Explicit tool annotations: Made annotation hints explicit (ReadOnlyHint, IdempotentHint, OpenWorldHint) instead of relying on default values, improving code clarity and ensuring that they're displayed correctly in the tiger mcp get output.
  • Shell completion helper: Added filterCompletionsByPrefix helper function to consolidate completion filtering logic
  • Tests: Added tests for the new tiger mcp get command.

Closes AGE-287

@nathanjcochran nathanjcochran self-assigned this Jan 14, 2026
@nathanjcochran nathanjcochran changed the title Add 'tiger mcp get' command for detailed MCP capability inspection Add 'tiger mcp get' command Jan 14, 2026
@nathanjcochran nathanjcochran changed the title Add 'tiger mcp get' command Add tiger mcp get command Jan 14, 2026
@nathanjcochran nathanjcochran marked this pull request as ready for review January 14, 2026 18:10
Askir
Askir approved these changes Jan 20, 2026
View reviewed changes
Copy link
Contributor

@Askir Askir left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally looks good :D Just left a few questions/suggestions.

internal/tiger/cmd/mcp.go Outdated
Short: "Get detailed information about a specific MCP capability",
Long: `Get detailed information about a specific MCP tool, prompt, resource, or resource template.

The type argument must be one of: tool, prompt, resource, resource_template
Copy link
Contributor

@Askir Askir Jan 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it strictly necessary that we include as an argument? Do we have collisions in names otherwise? I think it would be more intuitive otherwise to have tiger mcp describe create_service explain to the user that this mcp primitive is of type tool.

Copy link
Member Author

@nathanjcochran nathanjcochran Jan 20, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have collisions in names otherwise?

We don't currently have any collisions in names, but we theoretically could in the future (especially because pg-aiguide is developed separately from the CLI), since there's nothing that prevents a tool from having the same name as a prompt, for instance. I was really just trying to make it safe and future-proof.

If we make it tiger mcp get <name>, we would run into issues if we ever end up with duplicate names. Perhaps that's so unlikely that we just shouldn't worry about it? Idk, open to other thoughts on this. I just tend to err on the side of making things explicit and future-proof when there's potential ambiguity. And users can already figure out which things are tools vs prompts by running tiger mcp list, so it didn't feel like a major issue to me to require tool/prompt in the command. I agree that tiger mcp get <name> would be better in theory, though.

Copy link
Member Author

@nathanjcochran nathanjcochran Jan 21, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I decided to go ahead with your suggestion and remove the <type> argument, so now it's just tiger mcp get <name>: 545dd4c

If we run into naming collisions in the future, we can revisit 🤷‍♂️.

@nathanjcochran nathanjcochran merged commit ee66208 into main Jan 21, 2026
2 of 3 checks passed
@nathanjcochran nathanjcochran deleted the nathan/mcp-get branch January 21, 2026 16:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@Askir Askir Askir approved these changes

Assignees

@nathanjcochran nathanjcochran

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@nathanjcochran @Askir